Reconfiguration of a group of network nodes in an ad-hoc network

ABSTRACT

To improve consistency of software update in an ad-hoc network, it is proposed to prepare a transition from an initial software configuration to a target software configuration in a first step (S 10 ). Before deciding on commitment to the new software configuration, there is executed a step (S 12 ) to evaluate at least one reconfiguration result achieved at a further mobile device in the ad-hoc network. On the basis of this further reconfiguration result it may be decided whether after commitment to the new software configuration consistency of software versions may be maintained within the ad-hoc network. If this is not the case, e.g., due to a failure of software update in one of the mobile devices, a fallback to the initial software configuration is executed.

FIELD OF INVENTION

The present invention relates to a reconfiguration of a group of networknodes in an ad-hoc network, and in particular to a reconfiguration of agroup of network nodes in an ad-hoc network with particular emphasis onreconfiguration consistency.

BACKGROUND ART

In WO 01/14968 A1 there is described a fieldbus upgradable apparatus andmethod, wherein control devices residing on a fieldbus communicationsnetwork are modified without interrupting the operation of the controldevices in a seamless manner.

In U.S. Pat. No. 6,113,652 there is described a communication networkequipment capable of non-disruptive software upgrade which is used in atelecommunications network having a plurality of coupled nodes and anetwork controller coupled to at least one of these nodes.

Further, in U.S. Pat. No. 6,141,683 A there is described a method forremotely and reliably updating the software on a computer with provisionfor roll-back with particular focus on integrity between differentsoftware versions.

Further, in U.S. Pat. No. 5,699,275 there is described a system andmethod for remote patching of operating code located in a mobile unit,wherein a manager host is operable to initiate transmission through acommunication network of at least one discrete patch message defining atleast one patch.

Further, in US-2001/0029178 A1 there is described a wireless softwareupdate with version control in a wireless communication system having asystem backbone, having a host computer coupled to the system backbone,at least one base station coupled to the system backbone, and aplurality of mobile devices within the system.

Further, in WO 01/84792 A1 there is described a method and gateway forperforming an online switching of software in a communication system.

Overall, numerous factors associated with technology, business,regulation and social behavior have driven the spreading of wirelessad-hoc networking in the past, i.e., a wireless network formed withoutany central administration. Ad-hoc networks consist of a plurality ofmobile devices using a wireless interface for exchange of packet data.As each mobile device in the ad-hoc network serves as router and host,each such mobile device will forward data packets on behalf of othermobile devices and further run user applications. Therefore, in ad-hocnetworks, mobile devices are connected directly for local cooperation.

To support on-going improvement of functionality, an ad-hoc networksshould provide the opportunity for a software update. It is oftenrequired that all mobile devices in such an ad-hoc network have the samesoftware version, e.g., for reasons of compatibility. For this reason,the software update should take place in a coordinated manner,preferably at the same point in time. In addition, either all mobiledevices reconfigure successfully, or they all fall back to the softwareversion before installation.

However, up to now, no appropriate approach to the coordinated update ofsoftware in ad-hoc networks is available. Another issue not addressed sofar is that during reconfiguration, mobile devices may not communicateproperly.

SUMMARY OF INVENTION

In view of the above, the object of the present invention is to providea solution to consistent software reconfiguration in ad-hoc networks.

According to the present invention, this object is achieved through amethod of reconfiguration for a network node, e.g., a mobile device or astationary device, in an ad-hoc network. The method comprises a firststep of preparing a transition from an initial software configuration toa target software configuration and a second step to deciding oncommitment to the target software configuration. According to thepresent invention, the decision on commitment is taken in view of aresult of reconfiguration indicated through at least one further networknode in the ad-hoc network, in particular when every result ofconfiguration received at the network node from a reachable furthernetwork node is evaluated to be positive.

Therefore, according to the present invention, a transition from aninitial software configuration to a target software configuration is notexecuted anyway but such a transition is taken on the basis ofinformation being related to reconfiguration at network nodes beingreachable from the network node deciding on commitment to the targetsoftware configuration.

In particular, if the information received is related to furtherreconfiguration processes in the further network nodes, it is possibleto allow for coordination of reconfiguration between different networknodes, although each single network node is operating autonomously.

In other words, according to the present invention, it is proposed tonot simply initiate an update process for different network nodes in anad-hoc network and to just hope that the reconfiguration will besuccessful, but to use feedback mechanisms locally in each singlenetwork node to decide on commitment to target software configurations.

According to a preferred embodiment of the invention it is proposed tonegotiate a maximum reconfiguration time period between at least twonetwork nodes executing reconfiguration. The maximum reconfigurationtime is the maximum time for reconfiguration, indication ofreconfiguration result, and executing a fallback to the initial softwareconfiguration for network nodes in the ad-hoc network participating inthe reconfiguration process.

Further, preferably, a start of reconfiguration is coordinated betweenat least two network nodes in the ad-hoc network executing areconfiguration process. Optionally, one network node in the ad-hocnetwork may organize the negotiation process.

The negotiation of a maximum time for reconfiguration and the“synchronization” or coordination of start of reconfiguration are ofparticular relevance for achieving a simple, but nevertheless highlyefficient framework of autonomous reconfiguration in each network node.

The negotiation process of a maximum reconfiguration time period isadapted to a heterogeneous update of software within different networknodes, as the maximum time period for reconfiguration will be setaccording to the target software configuration in the network noderequiring the longest time period for reconfiguration.

Yet another advantage is that a time period during which services areinterrupted due to reconfiguration at the different network nodes isforeseeable and minimized. If after expiry of the negotiated maximumtime period no definitive reconfiguration success is established in thead-hoc network, immediately counter-measures may be taken to bring thead-hoc network back to operation on the basis of the initial softwareconfiguration before start of the reconfiguration process.

According to a further preferred embodiment of the invention, it isproposed to determine which network nodes are reachable after thereconfiguration process.

This preferred embodiment of the present invention is provided tocontrol two different reconfiguration scenarios.

A first scenario would be that reconfiguration is not related tocommunication software—e.g., like speech-codec software—but to some typeof application. Therefore, during reconfiguration communication is stillpossible. In such a case, connectivity from the network node executingthe reconfiguration process to further network nodes running thereconfiguration process is not an issue.

A second scenario would be that some type of communication-relatedsoftware is reconfigured so that it may not be guaranteed that thead-hoc network topology remains unchanged during the course ofreconfiguration. One example would be a communication software updatefailure at a specific network node which leaves the ad-hoc network as itmay no longer communicate with those network nodes which successfullyreconfigured communication software. Therefore, excluding this networknode from the commitment decision—after determination ofreachability—allows to avoid over-restrictive commitment decisions and arelated decrease in functionality improvement.

Further preferred embodiments of the present invention relate to thedecision mechanisms underlying the commitment to a new softwareconfiguration in a network node.

One option is to commit to the target software when every result ofreconfiguration received at the network node is positive. This type ofcommitment achieves maximum consistency of software versions afterreconfiguration as only a fully successful reconfiguration process atdifferent network nodes allows for transfer to the target softwareconfiguration in each single network node.

A further option relates to the other extreme case where no informationregarding the outcome of reconfiguration at other network nodes isreceived at all. In this case—after expiry of the maximumreconfiguration time period—it is proposed to execute a fallback to theinitial software configuration. The rationale behind this approach isthat, initially, communication was possible on the basis of the initialsoftware configuration. Further, the fact that no reconfiguration resultwas received at the network node deciding on the commitment to the newsoftware configuration is an indication that communication on the basisof the newly installed software is not possible. Therefore, fallback tothe initial software configuration is the optimal way to re-establishconnectivity in the ad-hoc network.

Yet another option is to execute a fallback to initial softwareconfiguration, when at least one negative reconfiguration result wasreported to the network node deciding on commitment to the targetsoftware configuration. The rationale behind this commitment decision isto maximize connectivity and communication capability. Assuming thatonly a single mobile network node could leave the ad-hoc networkaccording to the negative reconfiguration result, it is wise to continuethe operation on the basis of the initial software configuration tomaintain maximum connectivity.

Further preferred embodiments of the present invention relate to theinvolvement of a network node into the exchange of reconfigurationresults.

According to a preferred embodiment of the present invention, eachnetwork node either sends a positive or negative indication ofreconfiguration, according to the outcome of the transition from theinitial software configuration to the target software configuration.

It should be noted that the exchange of reconfiguration results may beachieved in various ways.

A first way would be to indicate the reconfiguration result throughdedicated positive or negative signals. Preferably, these signals may beprocessed, both, by through the initial software configuration and thetarget software configuration.

A second way would be to indicate a positive reconfiguration, e.g., ofcommunication software, implicitly through automatic set-up of networkconnectivity.

For both alternatives given above, the exchange of reconfigurationresults may be executed repeatedly to improve penetration ofreconfiguration results in the ad-hoc network.

A further preferred embodiment of the present invention relates to thedetermination of network nodes in the ad-hoc network participating inthe reconfiguration process.

According to the present invention, it is proposed to use a plurality ofcriteria for such determination which may be used either alone or incombination.

A first such criterion is communication capability of a network node.Here, it is proposed to have a match between the target softwareconfiguration and the related communication capabilities of a networknode. In other words, it would be meaningless to install communicationsoftware at a network node which is not applicable in view of thehardware support given by the network node. Further, communicationcapability may also be understood in the sense that only those networknodes are considered during software reconfiguration which support aspecific style of communication. A further criterion is networkconnectivity, which means that network nodes not being reachable in thead-hoc network are per se excluded from the reconfiguration process.

Yet another criterion may be profile data for a further detailedspecification of the network node or its end user. Such profile data mayclassify whether a network node supports specific types of serviceswhich form part of the reconfiguration process. Using such profile datait is possible to avoid unnecessary retrieval of software and relateddata traffic in the ad-hoc network.

Yet another criterion is a movement pattern of a movable network node,i.e. a mobile device, which may either be predicted or be known per se.Assuming that—in view of the movement pattern—a mobile device will soonleave the ad-hoc network, it is highly meaningful to avoid unnecessarydata traffic to such a mobile device for reconfiguration with respect toservices being of importance only within the established ad-hoc network.

Yet another criterion that might be used as basis for determiningnetwork nodes participating in the reconfiguration in an ad-hoc networkis a status of a network node, typically a hardware status. One suchexample would be the energy that is available within a network node,which is of particular relevance for mobile devices. Here, when theamount of energy is not sufficient to support a complete reconfigurationprocess, it is reasonable to exclude the network node from thereconfiguration process to avoid any disturbance of reconfiguration forthe remaining network nodes in the ad-hoc network. Another example of ahardware status may be the type of standard being supported forcircuit-switched or packet-switched communication through the networknode or processing power provided through processor devices in thenetwork node. The reconfiguration of services only makes sense when anetwork node offers a certain processing power required for certainservices.

Yet another example of a criterion to determine which network nodesshould be reconfigured could be a group membership of a network node,which group membership may be specified in advance. This criterion is ofparticular value for supporting different user groups or closed usergroups, e.g., in police departments or hospitals. Another grouping maybe according to companies, membership to specific organizations,profession of end user, etc.

Yet another criterion for determination of network nodes participatingin a reconfiguration could be a priority assigned to the end user of anetwork node. This criterion facilitates the ranking of end users, whichis of benefit for providers of commercial services aiming at userselectivity.

It should be noted that the determination of network nodes as outlinedabove could either be executed before start of reconfiguration or berepeated during the reconfiguration process. The latter option allows toidentify additional network nodes dropping out of the reconfigurationprocess, and therefore to minimize traffic in the ad-hoc network and toaccelerate the reconfiguration process.

Another preferred embodiment of the present invention relates toretrieval of software for executing the transition from the initialsoftware configuration to the target software configuration.

According to a preferred embodiment, software may be retrieved locallyfrom a portable electronic device, e.g., a smart card or any other typeof portable device that allows transfer of the related data.

Yet another option is to retrieve software via a mobile communicationenvironment of any type, e.g., from the Internet via a personal areanetwork, a wireless local area network, a wireless infraredcommunication network, Bluetooth communication, or any other suitabletype of mobile communication environment.

Further preferred embodiments of the present invention relate to thetype of software which is installed for reconfiguration.

As should be understood from the above, the present invention is notrestricted to any type of software. The present invention may be used toreconfigure application software, communication software, operatingsystem software, firmware, etc.

Further, the inventive reconfiguration process is not only related tosoftware as such, but also to related control parameters. Therefore, onemight imagine a situation where the software as such remains unchangedand only the parameter controlling the operation of the software arereconfigured in the sense outlined above.

According to the present invention, also heterogeneous softwarereconfiguration using network node specific software for transition tothe target software configuration is fully supported. Therefore, thepresent invention is perfectly suited to support softwarereconfiguration with utmost flexibility and user specific adaptation.

According to another preferred embodiment of the present invention thereis provided a computer program product directly loadable into theinternal memory of a network node of an ad-hoc network comprisingsoftware code portions for performing the inventive reconfigurationprocess when the product is run on a processor of the network node.

Therefore, the present invention is also provided to achieve animplementation of the inventive method steps on computer or processorsystems. In conclusion, such implementation leads to the provision ofcomputer program products for use with a computer system or morespecifically a processor comprised in, e.g., a mobile device like amobile telephone, a laptop computer, or a PDA.

These programs defining the functions of the present invention can bedelivered to a computer/processor in many forms, including, but notlimited to information permanently stored on non-writable storage media,e.g., read only memory devices such as ROM or CD ROM discs readable byprocessors or computer I/O attachments; information stored on writablestorage media, i.e. floppy discs and harddrives; or information conveyto a computer/processor through communication media such as networkand/or Internet and/or telephone networks via modems or other interfacedevices. It should be understood that such media, when carryingprocessor readable instructions implementing the inventive conceptrepresent alternate embodiments of the present invention.

BRIEF DESCRIPTION OF DRAWING

The best mode of carrying out the invention as well as preferredembodiments and examples will be explained with reference to thedrawing, in which:

FIG. 1 shows a network topology of an ad-hoc network to which thereconfiguration process according to the present invention isapplicable;

FIG. 2 shows a schematic diagram of a network node according to thepresent invention;

FIG. 3 shows a flowchart of operation for the network node shown in FIG.2;

FIG. 4 shows a schematic diagram of the software reconfiguration unitshown in FIG. 2;

FIG. 5 shows a flowchart of operation for different sub-units in thesoftware reconfiguration unit shown in FIG. 4;

FIG. 6 shows a flowchart of operation for the reconfiguration commitmentunit shown in FIG. 2;

FIG. 7 shows a first example of the reconfiguration process according tothe present invention; and

FIG. 8 shows a second example of the reconfiguration process accordingto the present invention.

DESCRIPTION OF BEST MODE AND PREFERRED EMBODIMENTS

In the following, the best mode of carrying out the present inventionand preferred embodiments thereof will be explained with respect to thedrawing. Throughout the specification, those parts being identical willbe referred to using the same reference numerals.

FIG. 1 shows a network topology of an ad-hoc network to which thereconfiguration process according to the present invention isapplicable. As outlined above, an ad-hoc network is a network formedwithout any central administration and consisting of network nodes,e.g., mobile devices or stationary devices, that use wireless interfacesto exchange circuit- or packet-switched data. It should be understoodthat there is not imposed any restriction either on the type of networknode nor on the type of communication in the ad-hoc network according tothe present invention.

Examples of network nodes are mobile devices like mobile telephones,PDAs, mp3-players, laptop computers, etc. or stationary devies likepersonal computers. Further, the type of ad-hoc networking may besuitably selected, e.g., on the basis of Bluetooth, HiperLAN/2, personalarea network PAN, IEEE 802.11, WLL Multi-hop Access Systems, accordingto the MANET initiative taken by the Internet Engineering Task ForceIETF.

The same also applies when the ad-hoc network is combined with a mobilecellular communication environment being operated on the basis of, e.g.,GSM, PDC, GPRS, UMTS, IMT2000, PHS, IS-95, or any hybrid combinationthereof.

Still further, it should be noted that the reconfiguration processexplained in the following is suitable for any type of software, such asapplication software, communication software, firmware, operation systemsoftware, and/or related control parameters.

Typical examples—without any binding effect on the presentinvention—would be mobile Internet application, mobile multi-mediaapplication, personalized service application, global mobility support,or any other type of video, still image, audio data, text data, orspeech-based application supporting software.

Further, communication-related software may be related, e.g., to speechcoding, source coding, channel coding, radio control according to anystandard like WCDMA, TDMA, FDMA, etc. Further, communication softwaremay be related to any ad-hoc network routing protocol, e.g., a distancevector routing protocol DSVD, an ad-hoc on-demand distance vectorrouting protocol AODV, and/or a dynamic source routing protocol. Stillfurther, examples of firmware could be a software which is necessary torun a signal processing unit, e.g., a DSP, which is usually availablewithin a mobile device.

FIG. 2 shows a schematic diagram of a network node according to thepresent invention.

As shown in FIG. 2, the network node 10 comprises a softwarereconfiguration unit 12 and a reconfiguration commitment unit 14.Further, for exchange of data in the ad-hoc network there is provided acommunication unit 16, and a memory unit 18 allows the storage of anydata involved with the operation of the network node 10.

FIG. 3 shows a flowchart of operation for the network node 10 shown inFIG. 2. Operatively, in a step S10, the transition from an initialsoftware configuration to a target software configuration is prepared,and in a step S12 there is taken a decision to commit to the newsoftware configuration in view of a related reconfiguration resultindicated through at least one further network node of the ad-hocnetwork.

Generally, the reconfiguration process is therefore split into twophases, a first one to prepare reconfiguration, and a second one toevaluate the reconfiguration result, to decide on commitment in the newsoftware configuration, and finally to actually commit to the newsoftware or to fall back to the initial software configuration. In thefollowing, further aspects underlying this basis concept of a two-phasereconfiguration process will be discussed in more detail.

Therefore, according to the present invention there is proposed anetwork node and method of reconfiguration thereof that ensureconsistent software update. This means that all network nodes have thesame consistent software version.

Within the general framework for a reconfiguration process as outlinedabove with respect to FIGS. 2 and 3, the present invention may be variedin a plurality of ways, as will be outlined in the following.

According to the present invention it is also proposed to determinenetwork nodes in the ad-hoc network executing the reconfiguration at thestart of reconfiguration. This is achieved on the basis of at least onecriterion: communication capability of a network node; nodeconnectivity; profile data of network node; movement pattern for amobile network node, i.e. mobile device; hardware status of networknode; priority of network node; and/or group membership of network node.

Communication capability may be related to any specific type ofcommunication—i.e., circuit-switched or packet-switched. Here, one mightconsider an application scenario where software being related topacket-switched communication is exchanged only, so thatcircuit-switched functionality remains unaffected. Therefore, networkndoes supporting circuit-switched communication only are not affected bythe reconfiguration.

In addition, network connectivity in the sense of the present inventionimplies that only network nodes being integrated into the ad-hoc networkshould be considered for reconfiguration. Optionally, profile data ofnetwork nodes is integrated into the decision of whether a network nodewill be reconfigured or not, which profile data may describe the type ofapplications, type of communication services, user preferences, etc.

Still further, the movement pattern as criterion for reconfigurationallows to drop out those mobile network nodes from the reconfigurationprocess which are in the process of leaving the ad-hoc network anyway.Therefore, an update of such a mobile network node with respect tospecific services in the current ad-hoc network becomes obsolete andshould be avoided.

Still further, hardware status of the network node is related both to adynamic hardware status or a static hardware status. A first example fora dynamic hardware status is the energy being available within thenetwork node, e.g., the load state of a mobile device battery. Only ifenough energy is available within the network node, the reconfigurationof such a network node is meaningful. Further, only if enough memory fora specific type of application software is available within the networknode—as example for a static hardware status—the network node should bereconfigured accordingly.

Still further, additional criteria for determination of reconfigurationare priority of a network node and group membership. Here, priorityassignment to a network node allows to exclude specific network nodesfrom reconfiguration and to have end users receiving privilegedservices. Group membership allows to set up different groups of networknodes and related end users forming ad-hoc networks and to supportorganizational aspects.

A further aspect of preparation of a transition from an initial softwareconfiguration to a target software configuration is related retrieval ofsoftware.

One option supported by the present invention is to download software toone network node being reachable in the ad-hoc network, and then todistribute the software to each network node participating in thereconfiguration.

Remote retrieval of software—e.g., from the Internet—may be achieved viaany type of mobile communication environment, e.g., a mobilecommunication network, a wireless local area network, a personal areanetwork, wireless infrared communication, and Bluetooth communication.Mobile communication may be executed according to any type of standard,i.e., IMT2000, GSM, PDC, PHS, IS-95.

According to the present invention, the reconfiguration supports alsoheterogeneous software update for different network nodes or, in otherwords, software reconfiguration may be achieved in a network nodespecific way. A further option would be to distribute softwarereconfiguration to at least two network nodes before subsequentdistribution within the ad-hoc network.

Yet another option for retrieving of software for reconfiguration wouldbe to use a portable electronic device IC/USIM in a local manner, suchthat the software necessary for reconfiguration is locally retrieved ateach network node. A modification of this approach would be that theportable electronic device is not only carrying software for a specificnetwork node, but for a plurality of network nodes, and that the networknode accommodating the portable electronic device is used fordistribution of the software to further network nodes.

Besides software retrieval via a mobile communication environment or aportable electronic device, a further option would be that softwarenecessary for reconfiguration is already pre-installed at a network nodeand therefore is only to be activated to achieve reconfiguration.

While above for selection of network nodes criteria and softwareretrieval mechanisms have explained as important aspects of the firststep S10 to prepare a transition from an initial software configurationto a target software configuration, in the following, important aspectsof the decision on commitment to a new software configuration accordingto step S12 shown in FIG. 3 will be explained.

The present invention relies on the understanding that thereconfiguration to the target software as such is not enough to provideconsistency of functionality of network nodes after reconfiguration.Therefore, in addition to the step of software update as first phase ofreconfiguration there is provided a second phase for evaluation of thereconfiguration result(s). The evaluation is a prerequisite to decide oncommitment to the target software configuration, and for actual transferto the new software configuration or establishment of a fallback processin view of the decision result.

In other words, only if a successful reconfiguration is notified withina negotiable maximum time for reconfiguration—indication ofreconfiguration result, and executing a fallback to the initial softwareconfiguration—through different network nodes participating in thereconfiguration process, there will be achieved commitment to targetsoftware configuration(s). Otherwise, there will be initiated a fallbackto the starting point of reconfiguration to re-establish communicationalso when the reconfiguration was not successful. This fallbackmechanism allows to maintain operability of the different network nodesin the latter case.

Further, the achievement of a reconfiguration process over differentnetwork nodes without central control is achieved through exchange ofindication of reconfiguration results between network nodes in thead-hoc network as will be explained in more detail in the following.

When communication is interrupted during preparation of transition tothe target software configuration a first option is to await theinstallation of the target software configuration and to then use thenew communication software for configuration result indication.Alternatively—i.e., when reconfiguration is not successful—a fallback tothe initial software configuration could be executed after the timeperiod reserved for reconfiguration, and then the previous initialsoftware configuration and related communication software may be usedfor reconfiguration result indication.

From the viewpoint of mobile device operating autonomously, any mismatchbetween the communication software after reconfiguration will be anindication to non-successful reconfiguration. To the contrary, asuitable exchange of data also after reconfiguration may be consideredas implicit indication of successful reconfiguration without exchange ofrelated dedicated signaling messages.

Further communication may also continue during the reconfigurationprocess, typically when no communication software is involved in thereconfiguration process. Here, the indication of reconfiguration resultsis easier and may be executed immediately after termination of thepreparation phase at each network node. Therefore, at the end of thetime period being available for configuration preparation, the decisionof commitment to the new software configuration and/or fallback to theinitial software configuration may be taken without any delay.

Optionally, the decision may be taken already before end of the maximumreconfiguration time period when positive reconfiguration indicationsare received from all involved network nodes before end of the maximumreconfiguration time period.

According to yet another case, a network node may not receive anyindication of a reconfiguration result at all, irrespective of whethercommunication is interrupted during the reconfiguration process orcontinuously available. In that case, where a network node is completely“blind”, the appropriate way is to execute fallback to initial softwareconfiguration of the network node before continuation of operation forthis network node.

While above general aspects of the present invention have been explainedwith respect to FIGS. 2 and 3, further details thereof will be explainedwith reference to FIGS. 4 to 6, respectively.

FIG. 4 shows a schematic diagram of the software reconfiguration unitshown in FIG. 2.

As shown in FIG. 4, the software reconfiguration unit 12 comprises anad-hoc network determination unit 20, a software retrieval unit 22, anegotiation unit 24, a coordination unit 26, and a timer unit 28,respectively.

FIG. 5 shows a flowchart of operation of the different sub-units of thesoftware reconfiguration unit 12 as shown in FIG. 4. The steps shown inFIG. 5 are basically related to the time period reserved for preparingthe transition from the initial software configuration to the targetsoftware configuration.

As shown in FIG. 5, at the beginning of this time period, the ad-hocnetwork determination unit 20 may determine network nodes in the ad-hocnetwork which execute a reconfiguration process in step S20 as outlinedabove. Then, in a step S22 the software retrieval unit will retrievesoftware according to the target software configuration as outlinedabove, and optionally also retrieve related software control parameters,e.g., parameters controlling the operation system of a network node.

In a step S24, the negotiation unit may negotiate a maximumreconfiguration time period for the network nodes participating in thereconfiguration process. It should be noted that the maximumreconfiguration time period covers the time period provided forpreparation of a transition to the target software state and, optionallya time period for evaluation of reconfiguration results, deciding oncommitment on the target software configuration and executing thecommitment or a fallback to the initial software configuration accordingto the determination result.

Then, in a step S26, the coordination unit 28 may coordinate start ofreconfiguration, when several network nodes execute reconfiguration suchthat different network nodes execute reconfiguration over the same timeperiod or, in other words, in a coordinated and/or synchronized way.This is supported through provision of a timer unit 28 which operativelystarts a reconfiguration timer to measure the actual reconfigurationtime against the negotiated maximum reconfiguration time in step S28.

As shown in FIG. 5, a further step S30—executed by the softwareretrieval and transition unit 22—achieves execution of transition to thenew software configuration. Step S30 divides into the sub-stepsinstallation of new software, indication of success of installation, andforwarding of received reconfiguration results. It should be noted thatthis transition is achieved autonomously in each single network node andthat the coordination is achieved through the reception and forwardingof reconfiguration results from further network node.

While each network node is operating autonomously, it is the continuousreception and forwarding of reconfiguration-related information thatallows to distribute reconfiguration status information in the ad-hocnetwork, which then may again be processed autonomously in each mobiledevice under the ad-hoc networking paradigm.

As shown in FIG. 5, the ad-hoc determination unit 20 may again beactivated after reconfiguration to execute step S32 for determination ofmobile devices which are reachable from a reconfigured network nodeafter installation of new software and transition to the target softwareconfiguration. This step S32 is particularly useful when network nodesare mobile and roam during the reconfiguration process, so that thead-hoc network topology changes.

FIG. 6 shows a flowchart of operation for the reconfiguration commitmentunit 14 shown in FIG. 2. The operation outlined in this flowchart isrelated to the operation after the first phase to prepare the transitionto the target software configuration or, in other words, afterexpiration of the timer provided in each network node to compare theactual reconfiguration time with the negotiated maximum negotiationtime.

As shown in FIG. 6, after expiration of the time period reserved forpreparing the transition to the new software configuration, thereconfiguration commitment unit 14 will evaluate whether areconfiguration result was received at all in a step S40. If this is notthe case, the reconfiguration commitment unit 14 will decide on fallbackto initial software configuration in a step S42.

Otherwise, the reconfiguration commitment unit 14 will determine whetherat least one negative indication for a reconfiguration was generatedduring the reconfiguration. If this is true, the reconfirmationcommitment will decide on fallback to initial software configurationaccording to step S42 Otherwise, a decision to commit to the targetsoftware configuration will be taken in a step S46.

The logic behind the decision mechanism shown in FIG. 6 is that theinterrogation whether no reconfiguration was received in step S40corresponds to a situation where a network node can no longer form partof the ad-hoc network, e.g., due to roaming and moving away of a mobilenetwork node from the area of the ad-hoc network. Here, a commitment toa target software configuration which might only be suitable for networknodes in the ad-hoc network would no longer make sense.

Further, the reason to decide on fallback when at least one negativeindication of reconfiguration is indicated is to guaranteeinteroperability and consistency also after reconfiguration.

However, in an alternative manner and depending on the number of networknodes participating in the reconfiguration and further the type ofreconfiguration, one could also consider a modification of the schemeshown in FIG. 6.

E.g., a statistical evaluation of the indicated reconfiguration resultsusing thresholds for acceptable negative reconfiguration level is aswell covered by the present invention.

It should also be noted that the ad-hoc network may split into severalgroups, each of which will have a common state of software version, butnot necessarily the same. E.g., in a first group, a network node mayhave to fall back, and therefore the complete group will execute afallback to the initial software configuration. To the contrary, theother group may achieve successful reconfiguration for all relatednetwork nodes.

FIG. 7 shows a first example of the application of the reconfigurationprocess according to the present invention.

For the example shown in FIG. 7 it is assumed that network nodes aremobile devices participating in the reconfiguration process. The mobiledevices are not roaming during reconfiguration. Further, it is assumedthat the battery of the mobile device T7 is too low, and that thereforethis mobile device will not participate in the reconfiguration process.

As shown in FIG. 7, mobile device T1 distributes the software accordingto the target software configuration for each of the mobile devices T2to T6. Then, the reconfiguration for all mobile devices takes place,except for mobile device T7.

At the end of the time period t reserved for reconfiguration, the resultof reconfiguration is as shown in the lower part of FIG. 7. While mobiledevices T3, T1, T4 to T6 execute the reconfiguration processsuccessfully, a failure occurs at mobile device T2 subsequent tosuccessful reconfiguration of the other mobile devices T1, T3 to T6. Thefailure is indicated to mobile devices T1, T3 to T6 using failuresignaling, e.g., a failure signal or message. At point of time t₀+t, allparticipating mobile devices T1 to T6 will decide on fallback to theinitial software version due to failure of the reconfiguration processat mobile devices T2. Alternatively, the same decision may be takenalready at receipt of the failure indication from mobile device T2.

FIG. 8 shows a second example of the application of the reconfigurationprocess according to the present invention. For the example shown inFIG. 8 it is assumed that different network nodes are mobile devicesthat may roam during the reconfiguration process.

As shown in FIG. 8, the reconfiguration process for mobile devices T2,T3, and T6 is executed successfully, while the reconfiguration processat mobile device T4 fails. In addition, shortly before end of the timeperiod reserved for preparing the transition to the target softwareconfiguration, connectivity between mobile devices T2 and T4 is lost,splitting the initial ad-hoc network T1 to T6 into partial ad-hocnetworks, T1, T2, T5, and T3, T4, and T6.

The reconfiguration process is successful for the first partial ad-hocnetwork T1, T2, T5, and therefore the first partial ad-hoc network willcommit to the target software configuration. To the contrary, the secondpartial ad-hoc network will execute a fallback to the initial softwareconfiguration due to failure of reconfiguration process in mobile deviceT4.

While in FIGS. 7 and 8 examples have been shown where communication ispossible during the first time period of the reconfiguration fordecision on commitment to the new software, an alternative would be thatcommunication is fully interrupted during the reconfiguration process.In the latter case, the reconfiguration result indication relatedexchange of information would be postponed until expiry of the timeperiod t reserved for software reconfiguration.

While above the best mode of carrying out the present invention as wellas further preferred embodiment thereof has been explained with respectto the drawing, it should be emphasized that all related featuresexplained with reference to the drawing may as well be combineddifferently to achieve additional variations and modifications of thepresent invention.

1-57. (canceled)
 58. Method of reconfiguration for a network node in anad-hoc network, comprising the steps: preparing a transition from aninitial software configuration to a target software configuration; anddeciding on commitment to the target software configuration in view of aresult of reconfiguration indicated through at least one further networknode in the ad-hoc network; wherein the step of committing to the targetsoftware configuration is taken when every result of reconfigurationreceived at the network node from a reachable further network node isevaluated to be positive.
 59. Method according to claim 58, wherein itfurther comprises a step of negotiating a maximum reconfiguration timeperiod with at least one further network node before executing thetransition from the initial software configuration to the targetsoftware configuration.
 60. Method according to claim 58, wherein itfurther comprises a step of coordinating a start of reconfiguration atthe network node with a start of reconfiguration in at least one furthernetwork node.
 61. Method according to claim 58, wherein it furthercomprises a step of determining network nodes being reachable from thereconfigured network node when ad-hoc network communication isinterrupted during the transition from the initial softwareconfiguration to the target software configuration.
 62. Method accordingto claim 58, wherein it further comprises a step of falling back to theinitial software configuration when at least one result ofreconfiguration received at the network node from a reachable furthernetwork node is evaluated to be negative.
 63. Method according to claim58, wherein it comprises a step of falling back to the initial softwareconfiguration when no result of reconfiguration result is received atthe network node until expiry of the maximum reconfiguration timeperiod.
 64. Method according to claim 58, wherein it further comprises astep of sending a positive reconfiguration result when the transitionfrom the initial software configuration to the target softwareconfiguration is successful.
 65. Method according to claim 58, whereinit further comprises a step of sending a negative reconfiguration resultwhen the transition from the initial software configuration to thetarget software configuration is not successful.
 66. Method according toclaim 58, wherein it further comprises a step of retrieving software forexecuting the transition from the initial software configuration to thetarget software configuration locally from a portable electronic device(IC/USIM).
 67. Method according to claim 58, wherein it furthercomprises a step of retrieving software for executing the transitionfrom the initial software configuration to the target softwareconfiguration remotely via a mobile communication environment. 68.Method according to claim 9, wherein it further comprises a step ofpre-installing software for executing the transition from the initialsoftware configuration to the target software configuration in thenetwork node.
 69. Network node for operation in an ad-hoc network,comprising: a software reconfiguration unit adapted to prepare atransition from an initial software configuration to a target softwareconfiguration; and a reconfiguration commitment unit adapted to decideon commitment to the target software configuration in view of a resultof reconfiguration indicated through at least one further network nodein the ad-hoc network; wherein the reconfiguration commitment unit isadapted to commit to the target software configuration when every resultof reconfiguration received at the network node from a reachable furthernetwork node is evaluated to be positive.
 70. Network node according toclaim 69, wherein it further comprises a negotiating unit adapted tonegotiate a maximum reconfiguration time period with the at least onefurther network node before executing the transition from the initialsoftware configuration to the target software configuration.
 71. Networknode according to claim 69, wherein it further comprises areconfiguration coordination unit adapted to coordinate a start ofreconfiguration at the network node with a start of reconfiguration inthe at least one further network node.
 72. Network node according toclaim 69, wherein it further comprises a connectivity unit adapted todetermine network nodes being reachable from the reconfigured networknode when ad-hoc network communication is interrupted during thetransition from the initial software configuration to the targetsoftware configuration.
 73. Network node according to claim 69, whereinthe reconfiguration commitment unit is adapted to decide on falling backto the initial software configuration when at least one result ofreconfiguration received at the network node from a reachable furthernetwork node is evaluated to be negative.
 74. Network node according toclaim 69, wherein the reconfiguration commitment unit is adapted todecide on falling back to the initial software configuration when noresult of reconfiguration result is received at the network node untilexpiry of the maximum reconfiguration time period.
 75. Network nodeaccording to claim 69, wherein it further comprises a communication unitadapted to send a positive reconfiguration result when the transitionfrom the initial software configuration to the target softwareconfiguration is successful.
 76. Network node according to claim 69,wherein it further comprises a communication unit adapted to send anegative reconfiguration result when the transition from the initialsoftware configuration to the target software configuration is notsuccessful.
 77. Network node according to claim 69, wherein it furthercomprises a software retrieval unit adapted to retrieve software forexecuting the transition from the initial software configuration to thetarget software configuration locally from a portable electronic device.78. Network node according to claim 69, wherein the software retrievalunit is further adapted to retrieve software for executing thetransition from the initial software configuration to the targetsoftware configuration remotely via a mobile communication environment.79. A computer program product directly loadable into the internalmemory of a network node of an ad-hoc network, comprising software codeportions for performing the steps of claim 58, when the product is runon a processor of the network node.